The reason musl special-cases SIGTIMER (32), SIGCANCEL (33), and SIGSYNCCALL (34) is that they're used in the implementation of pthread and timer APIs in musl.

The libc-less version of Zig's standard library does not use these signal numbers for anything, and the app_mask and all_mask constants are only used in the Linux implementations of raise() and abort() in std.posix when libc is not linked.

I'm inclined to say that, rather than adjusting app_mask, it should just be deleted in favor of using all_mask in raise() instead. But maybe there's some factor I'm missing here. cc @andrewrk since these constants were added in 6f1a7a0.

I'm wondering why raise() need to block and unblock signals. musl does this, but glibc does not. I think we can remove the block&unblock pair.

musl does this, but glibc does not. I think we can remove the block&unblock pair.

Maybe. I'd still like Andrew's thoughts on this before we go ahead with that change.

Also, perhaps the same would be true of abort()?

Also, perhaps the same would be true of abort()?

Current implementation of abort() first uses raise() then goes through the block/unblock pair. I guess in most cases (no user-installed handler) the process will just terminate at the first raise(). If it is not, it is necessary to use the block/unblock pair and reset the signal handler when all signals are blocked to avoid race condition.

ping @andrewrk.

Any updates on this? @alexrp @andrewrk

I'm wondering why raise() need to block and unblock signals. musl does this, but glibc does not. I think we can remove the block&unblock pair.

https://git.musl-libc.org/cgit/musl/commit/?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9

This actually seems like a pretty good reason to keep the signal blocking.

However, we can just block all signals rather than only blocking "application signals" as defined by musl. musl makes this distinction because musl knows that the signal handlers for its internal signals (SIGTIMER, SIGCANCEL, and SIGSYNCCALL) are well-behaved and won't fork(). So it's just just a minor optimization AFAICT, and again, we don't have a concept of internal signals in the libc-less Zig standard library.

I'm wondering why raise() need to block and unblock signals. musl does this, but glibc does not. I think we can remove the block&unblock pair.

https://git.musl-libc.org/cgit/musl/commit/?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9

This actually seems like a pretty good reason to keep the signal blocking.

However, we can just block all signals rather than only blocking "application signals" as defined by musl. musl makes this distinction because musl knows that the signal handlers for its internal signals (SIGTIMER, SIGCANCEL, and SIGSYNCCALL) are well-behaved and won't fork(). So it's just just a minor optimization AFAICT, and again, we don't have a concept of internal signals in the libc-less Zig standard library.

Modified.